Compiler Knows Rebuttal
Volume Number: 8
Issue Number: 6
Column Tag: Article Rebuttal
A Rebuttal to "The Computer Knows" Article
By Tim Swihart, Co-Author "Programming for System 7
Just a couple of notes on the August issue (which arrived in my mailbox this
weekend, so hopefully not too many other have yet mentioned some of this stuff).
• First off, great issue, v2.0 looks better with each new issue. Gar's column was
great tounge-in-cheek fun!
• Secondly, a quick rebuttal to a portion of one of the articles in the August '92
issue. The problem is in John Love's “The Compiler Knows” article. The
problem is on page 30, left hand column. John hard codes the menu ID for the
item he appended to the help menu (#define myItem 3). That's very bad! Inside
Mac, Volume VI, page 11-63 says, "In the future, Apple may choose to add other
items to the Help menu. To determine the number of items in the Help menu, call
the CountMItems function, which is described in the Menu Manager chapter of
Volume 1.
In English, that translates to, "Don't hard code the ID of the item you append to
the Help menu because the actual ID will change if Apple ever adds items to, or removes
items from, the Help menu. Instead, let the toolbox tell you what ID was assigned to
your item - since your item will always be at the end of the menu, CountMItems gives
you the ID of the appended item.
This is a simple example of why existing applications break when new operating
system features are added. In this case, doing it right is simple, so there's no reason to
not do it right.
Also, John's code doesn't show what to do if your app added multiple items in the
Help menu. How do you figure out which is which? "Programming for System 7" (Gary
Little and Tim Swihart, Addison Wesley) shows how to handle it cleanly in Listing 8-5
(page 289). To paraphrase that approach (error checking and type declarations have
been removed to simplify this explanation):
/* 1 */
HMGetHelpMenuHandle(&myHelpMenuHndl);
bottomHelpItem = CountMItems(myHelpMenuHndl);
secondHelpItem = bottomHelpItem - 1;
thirdHelpItem = bottomHelpItem - 2;
if (pickedItem == bottomHelpItem) {
// code to do what you want when last item picked
} else {
if (pickedItem == secondHelpItem) {
// code to execute when second to last item picked
} else {
if (pickedItem == thirdHelpItem) {
// code for third to last item being picked
}
}
}
One last point to make while on the subject of the Help menu. There are
third-party inits available that remove the Help menu (freeing up that tiny bit of
menubar space it occupies). But, some of them can have unexpected side effects on
applications that assume they'll have a Help Menu since the Help Manager is present
(which normally seems like a relatively valid assumption). Checking for errors
returned by HMGetHelpMenuHandle() isn't enough. You'll also need to verify that the
returned handle isn't nil if you want truly bulletproof code. Here's how I handle this in
"BNDL Banger Pro":
/* 2 */
/* The following routine is responsible for appending */
/* application-specific help items to the 'Help' menu. */
/* It's called from "Initialize()", just before */
/* "DrawMenuBar()" is called. */
void DoAddHMItems(void)
{
MenuHandle myHelpMenuHndl;
OSErr myErr;
myErr = HMGetHelpMenuHandle(&myHelpMenuHndl);
if ((!myErr) && (myHelpMenuHndl != nil)) {
// check for nil in case some has removed the help menu
// (stop snickering, I'm serious - there are such
// hacks readily available now)
AppendMenu(myHelpMenuHndl,
(ConstStr255Param)"\pBNDL Banger Pro Instructions");
}
}
• Shifting gears considerably, I'd like to offer one last suggestion. Include the
phone number for the MouseHole BBS in the MouseHole report section. [Right
now, the Mousehole is on hiatus. Larry Nedry is the middle of a move to Texas. So
for now, we can’t be of help here. - Ed.]
Thanks for listening.